1. Technical Field
The present invention relates generally to data processing systems such as computer systems, and more particularly to proxy-based API translations for multiple different firmware versions.
2. Description of the Related Art
A computer system includes firmware which provides an interface between the computer system's hardware and software. Typically, an operating system interacts with the hardware utilizing the firmware.
The hardware of a computer system is often revised and improved. It is desirable for software applications to interface with different versions of a computer system. When updates to the hardware occur, the firmware is also usually updated. Thus, the software applications that run on this hardware may need to interact with different versions of firmware so that the software application can interact with the different versions of firmware.
Each version of firmware will include a set of application programming interfaces (APIs) which are used by the software for accessing the firmware. One method for permitting software to interact with the firmware API is to provide interfaces, for example remote procedure calls (RPCs), between the software layer and the firmware API layer. The firmware interface includes methods and classes that are used to represent the current configuration of the hardware and to change the configuration. To differentiate the classes from one firmware release to another for a particular type of API, the firmware changes the class name such that a different Java class name exists for each firmware release for that type of API. The interface software must be written so that it will recognize the different class names for each firmware release. To create a separate class for each method call for each release would create a lot of interface code. In addition, most of the interface code for a new release would be duplicated from the previous release. These interfaces each represent a small slice of the total firmware APIs. Therefore, in order to represent all of the firmware APIs, many interfaces are required. For example, there may be hundreds of interfaces which when taken together represent an entire set of firmware APIs.
These firmware APIs are specific to a particular version of the firmware. Thus, software that was written to access a version of firmware using one set of firmware APIs will not be able to access a different version of firmware which uses a different set of firmware APIs. The interfaces can be thought of as a software layer above the firmware API layer. These interfaces must have information about a specific version of firmware APIs.
The prior art provides for code that recasts an interface call to a particular firmware version API call. This code consists of a collection of different classes that recast the interface to each version of firmware. For each interface, there will be as many classes as there are firmware versions in order to recast the interface for each version. This code is referred to below as an implementation instance. Thus, there is a different implementation class to create each implementation instance for each interface for each version of supported firmware. When there are hundreds of interfaces, hundreds of classes are necessary to permit the interfaces to interact with each possible firmware API version.
For example, FIG. 1 is a block diagram, which follows the Unified Modeling Language (UML) notation, that depicts two different interfaces and the classes that are necessary to support these interfaces with different versions of firmware in accordance with the prior art. An interface A 100 represents a portion A of the firmware. An interface B 114 represents a portion B of the firmware. Interface A 100 may access a portion A instance of version 1 104 of the firmware using implementation A version 1 instance 102. Thus, when interface A 100 is used in a system that includes firmware version 1, implementation instance 102 is used to access portion A.
Interface A 100 may access a portion A instance of version 2 108 of the firmware using implementation A version 2 instance 106. Interface A 100 may access a portion A of version 3 112 of the firmware using implementation A version 3 instance 110.
Interface B 114 may access a portion B instance of version 1 118 of the firmware using implementation B version 1 instance 116. Interface B 114 may access a portion B of version 2 122 of the firmware using implementation B version 2 instance 120. Interface B 114 may access a portion B of version 3 126 of the firmware using implementation B version 3 instance 124. For example, implementation A version 1 instance 102 implements interface A 100 and recasts the APIs found in interface A 100 into their equivalent version-specific APIs of firmware A version 1 instance 104.
Each implementation instance is an instance of a different class. For example, implementation A version 1 instance 102 is an instance of implementation A version 1 class 130. Implementation A version 2 instance 106 is an instance of implementation A version 2 class 132. Implementation A version 3 instance 110 is an instance of implementation A version 3 class 134. Implementation B version 1 instance 116 is an instance of implementation B version 1 class 136. Implementation B version 2 instance 120 is an instance of implementation B version 2 class 138. Implementation B version 3 instance 124 is an instance of implementation B version 3 class 140. Therefore, in order to implement an interface a particular number of firmware versions requires that number of classes. This number is multiplied by the total number of interfaces in order to implement all of the firmware APIs.
In addition, there are other objects that do the work of creating the implementation instance from the implementation classes. There is a factory object to create a factory instance for each firmware version for creating the implementation instances for each version of firmware. FIG. 2 is a UML diagram that illustrates a factory interface that may be used to create factory objects in accordance with the prior art. Factory interface 200 may be used to create factory instance version 1 202, factory instance version 2, 204, and factory instance version 3 206. Factory instance version 1 202 is an instance of factory class version 1 208. Factory instance version 2 204 is an instance of factory class version 2 210. And, factory instance version 3 206 is an instance of factory class version 3 212.
Factory instance version 1 202 may be used to create the implementation instances for each interface for firmware version 1. Factory instance version 1 202 is used to create implementation A version 1 102 and implementation B version 1 116. Factory instance version 2 204 is used to create implementation A version 2 106 and implementation B version 2 120. And, factory instance version 3 206 is used to create implementation A version 3 110 and implementation B version 3 124. Whenever a new firmware version needs to be supported, a new factory instance must be created which will create the implementation instance for each interface for that version.
As should be apparent from the description above, many thousands of lines of code must be written to create all of the implementation classes and factory classes that are needed to create the various objects.
Therefore, a need exists for a method and system for reducing the amount of code that is needed to support multiple different versions of firmware.